The present disclosure relates to the data processing field. More specifically, this disclosure relates to multi-tenant software applications.
Multi-tenant software applications are used to serve multiple users (referred to as tenants) by each instance thereof (instead of having a separate instance of the software application for each user). For this purpose, each multi-tenant software application is designed to partition die data of its tenants logically (for example, by means of corresponding filters); in this way, each tenant is provided with a virtual software application emulating a dedicated instance of the multi-tenant software application. The multi-tenant software applications provide significant cost savings and management simplifications.
A typical example is in a cloud computing (or simply cloud) environment, wherein users of a communication network are allowed to exploit computing resources on-demand as services (referred to as cloud resources and cloud services, respectively); the cloud services are made available by cloud providers, which provision, configure and release the cloud resources upon request (so that their actual implementation is completely opaque to the users). In this way, the users are relived of the management of the actual physical resources that are needed to implement the cloud resources (for example, their installation and maintenance); particularly, this provides economies of scale, improved exploitation of the physical resources, and high peak-load capacity. Moreover, the users are now allowed to perform tasks (on a pay-per-use basis) that were not feasible previously because of their cost and complexity (especially for individuals or small companies). The de-coupling of the cloud resources from their implementation provides the illusion of an infinite capacity thereof; moreover, the de-localization of the physical resources implementing the cloud resources enables the users to access them from anywhere. In this case, the multi-tenant software applications may be provided by corresponding services that are delivered on-demand by the cloud providers according to the Software-as-a-Service (SaaS) model.
The tenants of each multi-tenant software application are routinely added and deleted. A typical example is when a “try and buy” mechanism is implemented to acquire new customers. In this case, a trial period is offered for evaluating the delivered service free of charge (after which the service may be actually subscribed to with the payment of a corresponding fee). Usually, a same instance of the multi-tenant software application is used to serve both tenants in the trial period and tenants subscribed to the service; in this way, the conversion of every tenant in the trail period that decides to subscribe to the service simply requires changing its status, without the need of any migration of the corresponding data.
Whenever a tenant is deleted (for example, when the service is not subscribed to after the trial period), the corresponding data is removed. Moreover, a slot of resources of the multi-tenant software application assigned to the deleted tenant (comprising the filters for accessing the corresponding data) is freed, so as to return available for a new tenant.
However, some data of the tenants may be stored in shared structures for all the tenants (for example, log files) that do not have a granularity allowing its deletion individually at the level of each tenant. Therefore, until these shared structures are purged (for example, periodically) so as to remove the data of all the tenants, comprising the ones to the deleted, no new tenants may be re-assigned their slots (since otherwise the new tenants would be granted access to the data of the deleted tenants by means of the corresponding filters).
The resulting delay in the re-assignment of the slots of the tenants to be deleted may require the deployment of new instances of the multi-tenant software application. Indeed, each instance of the multi-tenant software application usually may serve a number of tenants at most equal to a maximum value for performance reasons (for example, to comply with a corresponding Service Level Agreement, SLA). Therefore, when the number of tenants in all the instances of the multi-tenant software application has reached this maximum value, no new tenant may be allocated thereto; this happens even if some of the tenants are to be deleted, but the corresponding slots may not be re-assigned yet since their data is still stored in the shared structures. In this case, a new instance of the multi-tenant software application is to be deployed for serving the new tenant.
The resulting higher number of instances of the multi-tenant software application involves corresponding cost increases and management complications (comprising for the distribution of the new tenants throughout them).